1. Technical Field
The present invention relates to an addressing scheme for accessing application servers in a communications network and to related aspects. In particular but not exclusively to a scheme for addressing the host server of a third party web service running on a mobile communications device from a web browser application. In particular, but not exclusively, the addressing scheme enables mobile devices located within private address domain(s) to be contacted by other devices on the same LAN segment.
In particular, but not exclusively, the addressing scheme according to the invention seeks to enable mobile web-service providing devices located within private address domains to be contacted by other devices located on the same LAN segment regardless of whether or not the two devices are located in the same private IP address domain, providing a working network path can be identified directly or indirectly between the two devices. In this way, if a device-label (such as a telephone number which is associable with an addressed device) is provided by an addressing device to an addressing server, the server is able to resolve the device-label to a private address via which the addressing device can contacted. The private address is utilized by the web-browser application to seamlessly and transparently obtain a requested web-service from the addressed device using any suitable communications channel, e.g. WiFI, Bluetooth, etc, that provides a working path between the two devices.
The term “LAN segment” refers here to an area within which a device can use an Address Resolution Protocol request to look up and resolve the local address of other device (regardless of whether or not both devices are located in the same private address domain or in different private address domains).
2. Related Art
Network address translation (NAT) devices are known to enable reuse of the Internet Protocol (IP) address space by separating private IP address domains from public IP address domains. NAT techniques establish and maintain Transmission Control Protocol/Internet Protocol (TCP/IP) network and/or User Datagram Protocol (UDP) connections traversing NAT gateways. NAT techniques are used for client-to-client networking applications such as Voice-over-IP (“VoIP”) and peer-to-peer applications (for example, file-sharing). When one or both devices (i.e., the client/service providing device) are mobile and have only intermittent connectivity however, NAT can cause problems as it disrupts the end-to-end connectivity. Several NAT control protocols exist, including Universal Plug and Play (UPnP) which typically used in a home/small office environment.
NAT enables private IP addresses to be used on home and corporate networks (internal networks) behind routers which present a single public IP address to the public Internet. When a networked device located in the private IP address domain behind the NAT gateway/router communicates with a device in the public network, the NAT device changes the source address of any outgoing requests the network device generates to the NAT device's own address.
The number of devices participating as servers whose IP addresses are allocated in the private domain behind a NAT device is increasing. The use of applications such as peer-to-peer file sharing (for example, BitTorrent™ or Gnutella™), interactive applications such as video conferencing, VoIP (for example, Session Initiation Protocol or SIP), as well as electronic gaming is also increasing. Whilst the NAT technique works well for devices which function as clients and initiate communications, as the outgoing request enables replies received by the NAT device to be forwarded back to the originating device using an appropriate method, the NAT device has no automatic method for determining from an incoming communication seeking to initiate contact with a server which device located in the private address domain is actually providing that server functionality.
The growing use of mobile devices offering services has further complicated this scenario. As has the increased use of web applications which integrate a number of services provided by multiple independent web sites within a single browser application, known in the art as “Web-based mash-ups”. For example, the use of the Google™ Maps application within a unrelated application allows location and other information generated by the unrelated application to be displayed on a map generated using the Google™ Maps application.
Service integration is conventionally implemented either by integrating the third party service in the origin server, or in the web browser itself. Where the third-party service is integrated from the origin server, a variety of network protocols are available for use to support the service integration, for example, the SOAP™ based WebServices protocol. Where service integration take places in the web browser, background mechanisms which rely on dynamic <script> tag loading can be used, for example, an eXtensible MarkUp Language HyperTextTransferProtocol request (XMLHTTPRequest) or a JavaScript Object Notation (JSON) based interface.
Known service integration schemes require the address of the hosting web server to be known in advance by the web application author and hard coded into the web content. When a web-browser application running a device runs a web application with the third party content address hardcoded in a particular HyperText Markup Language (HTML) page, providing the browser security policy has been configured to authorize the web application to request content from the address of the third-party content, the requested third party web service accessed via that address will be integrated into the HTML page running in the web browser application on device.
Local networked appliances within the home are becoming more prevalent and such appliances are now capable of providing web based interfaces to allow the user to manually configure and control the appliance remotely. The local area network (LAN) device addresses for such domestic appliances are typically allocated dynamically according to the Dynamic Host Configuration Protocol (DHCP) configuration of the LAN router.
If a LAN device is a mobile device and only intermittently connected to a LAN, its IP address will not be static and can change on a frequent basis. In order to enable devices on the LAN to detect each other and determine their address a number of different schemes have been proposed such as Universal Plug And Play (UpnP), Bonjour™, etc which use multicast broadcast packets to announce the availability, address of particular devices as well as the type of services these devices offer. These protocols provide address discovery to allow client applications on a LAN to discover the address and name of a dynamically available device in order to connect to it.
In UPnP the URL of the web services provided by the device is included in the service announcements. These URLs can be displayed by the UPnP aware clients and can be passed to a web browser application as the initial address to fetch the HTML content from.
Web browser applications such as Internet Explorer™ and FireFox™ use the hierarchical Domain Name System (DNS) address lookup scheme to resolve the domain name of a hosted web service to the actual Internet Protocol (IP) address and port to connect to of the server which is hosting the web service. For example, Internet Explorer makes a DNS lookup query for Type A records (hostname) addresses. These requests are first resolved in the DNS cache of the host machine, before being passed to the local DNS server for the LAN (typically hosted in the router) before being referred by the router to the parent DNS server if unresolved. If the hostname is not defined in the DNS cache or local DNS server then the web service will be unreachable.
This imposes a constraint on the way web-services are integrated. In order for a web application to be developed which integrates Wide Area Network (WAN) and LAN web services essentially two mechanisms are available. Either when running the application provides a prompt for user input to enter the IP address of the local device which is hosting the desired third party LAN or WAN web-service or a plug-in application such as an ActiveX or Java applet which implements an address discovery protocol such as UPnP or Bonjour™ must be integrated into the web application together with a JavaScript Application Program Interface (API) to allow this information to be conveyed into the HTML execution context of the web-browser.
A user may not be able to identify the host name or UPnP name of the device hosting the desired third-party service. A default address for a third-party service may have no association with a device which is apparent to a user. The name may bear no relation to a user's concept of a device name and may also assume that the user has actually configured a unique name for the device and not relied on some default naming convention adopted by the device manufacturer.
An exception is when the LAN device hosting the third-party service is a telephone-type device, as the unique device ID is the phone number associated with the phone device, which a user may be aware of and if not, can usually determine.
Accordingly, if a user is prompted for a telephone number for a device to enable that device to provide a web-service to the user's device, it is likely that the correct telephone number may be provided. This means a web content author can realistically develop a web application which includes a prompt for a user to enter a phone number for a device which is to provide a required third-party web service in order to integrate that web service at the runtime of the web application, providing the phone number entered by the user is capable of being converted into a IP address on the local LAN of the device which is hosting the third-party web-service.
It is well known that certain predefined names can map to specific devices. For example, “localhost” is a well known name that matches to the 127.0.0.1 IP loopback address of the current device. This is utilized by plugin's such as the http://developer.garmin.com/web-device/garmin-communicator-plugin/ which provides a Javascript API to a web browser plugin that allows a web application to talk to a Global Positioning Service (GPS) device connected on a Universal Serial Bus (USB) port to the device hosting the web browser application. The Apple™ proprietary Bonjour™ and the UPnP standard both use multicast DNS to broadcast the IP address of a named device to other computers on the same LAN as the named device. However, both of these systems require that an application which needs to perform device name to IP address conversion is either Bonjour™ or UPnP aware.
The DNS service discovery (DNS-SD—see, for example, http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt for more details), provides a mechanism to find services on a local LAN using DNS. This system uses service (SRV) type records (see Request For Comment (RFC) 2782 available from the Internet Engineering Task Force (IETF) standards body for more information about locating services using DNS and SRV records) in the local DNS database to provide a service to IP address and port lookup mechanism.
In order to use DNS-SD, an application incorporating a third party web-service must be aware that the address it has obtained for the third party server hosting that third party web-service is not correct in order to trigger a request to perform a SRV lookup. As web browser applications are conventionally configured to automatically assume when accessing a web-service that a given web-service address host name is the correct for that web-service, the application will automatically use the given hostname to perform a lookup on the hostname field in the DNS database, regardless of whether that hostname is accessible or not or whether it is the correct hostname or not for the requested service. As a result, existing web browsers do not trigger the DNS-SD SRV lookup procedure.
RFC3761 describes a standard mechanism for converting a telephone number into a domain name. Essentially the number is reversed, the digits separated by “.” and postfixed with the .e164.arpa domain. This RFC ensures that unique phone numbers can be converted to unique domain names but then relies on standard DNS to resolve the *.e164.arpa domain to an IP address.
Dynamic DNS (DDNS) provides a mechanism for devices to dynamically update the IP address to domain name mapping via a internet resident server. This server ensures that only authorized clients are allowed to change the IP address for a domain. DDNS is typically used for supporting remote access to home networks where the public IP address of the home router is dynamically allocated by the ISP.
The DDNS client is responsible for automatically detecting the IP address change and update the DDNS server. However, the new IP address must then propagate across the internet to other domain name servers in the internet and as such only becomes reliably available after a period of time has passed. The amount of time varies as it depends on the rate at which DNS updates are disseminated across the domain name servers in the internet.
The delay between the update occurring and it being made available is set by the TimeToLive (TTL) value set by the DDNS name server. This would typically be 1 hour, however since name lookups are not made to the DDNS server but typically to an Internet Service Provider's ISPs DNS server, the time for a new IP address change to percolate depends on both the TTL and whether other DNS servers respect the TTL.
DDNS services also allow client to register private IP addresses, however such private IP addresses are only valid if the device requesting the lookup and the server are on the same LAN segment.
United States Patent Application US20070214209 describes a DDNS style service in which an addressing database holds additional information relating to a device address. However, US20070214209 does not consider the criteria for providing an IP address for a device located on the same LAN segment as the address querying device. US 20070214209 considers the geographical proximity between the querying device and the device whose address is being queried, however, geographical proximity between two devices does not imply they are on the same LAN segment. For example, two devices may be connected on a 3G wireless communications network and be physically adjacent to each other in the same location despite one device not being connected to a LAN which the other device is connected to. Even if both devices are connected to the same physical wireless network, for example, if both devices are connected to a WiFi LAN via the same WiFi Access Point, one device may not be capable of addressing another if the WiFi access point implements wireless client separation. WiFi hotspot routers will enforce wireless client separation by not indicating a route can be established between two devices so that even where two devices are on the same WLAN their presence is not automatically indicated to each other.